1. Field of the Invention
The present invention relates generally to an improved data processing system and in particular to a method and apparatus for monitoring the execution of code. Still more particularly, the present invention relates to a computer implemented method, apparatus, and computer usable program code for generating notifications in response to selected conditions occurring during the execution of code.
2. Description of the Related Art
In designing and writing code for applications, one objective is for the application to scale well when more than one processor is used. A complex application, such as, WebSphere™ Application Server, may support may different transactions. It is important that this application be able to take advantage of multiple threads and multiple processors. When the work load increases, an application that scales well should be able to take advantage of multiple processors and have better performance than when only a single processor is available. If the application does not scale well, then the availability of additional processors does not necessarily improve performance. In fact, the availability of additional processors may actually degrade performance.
Currently, determining why an application does not scale is often a very difficult problem. One aspect of understanding the scaling of applications is to determine why a monitor, such as a Java monitor is being held. A monitor is an object with a built-in mutual exclusion and thread synchronization capability. A monitor is used as a mechanism to provide serial access a resource. A monitor, sometimes called a lock, is used by a synchronized Java method. A synchronized Java method is one in which only one thread may use this method at a particular time. Threads that do not have access to the method have to wait until the monitor is released before it can use the method associated with the monitor.
Thus, with the use of a monitor, one particular thread may hold or own a monitor to access a resource. Numerous other threads wait their turn to own the monitor to access the resource when he particular thread releases the monitor. Understanding why the monitor is being held by a thread is often helpful in determining why an application does not scale. The current approach for obtaining information about monitors being held is to generate a call every time a request is made for a monitor. This type of approach is too invasive, because the act of making a call out drastically affects the performance and timing of the system being tested. The profiling code may be much more significant than the code being profiled.
Another aspect of understanding why an application does not scale involves determining why a routine is waiting. A thread may wait for a requested operation or function to be completed. For example, a thread or routine may request data to be read from a storage device. This thread or routine is placed into a waiting mode until the operation to return data is completed. Waiting occurs for any type of input/output (I/O) in these examples. Understanding why routines are waiting also is useful in determining why an application is not scaled.
Currently, this type of information is obtained by generating notifications or calls for all wait and notification mechanisms used in a particular environment. This type of notification also is considered too invasive. Again, the code to make the call out, receive the call out, and make a determination of importance may include much more than just the code that processes the event. This type of perturbation affects the value of the profiling. What is needed is a methodology for being selective in the notifications to minimize the overall invasiveness of the profiling.